Repository navigation
doc: documenter l'archivage fiable d'un projet - #128
Conversation
Co-authored-by: Automata <automata@shikanime.studio>
StephaneTrebel
left a comment
There was a problem hiding this comment.
L’ordre verrouillage → nettoyage externe → archivage, les statuts et les erreurs 422/409 correspondent au code Console actuel, mais l’idempotence de tous les nettoyages est affirmée à tort : le cas contraire reste documenté dans Console #2785 et présent dans le chemin project.delete, comme détaillé inline. Les liens locaux, la structure Markdown et Test app build sont valides ; aucune suite applicative locale n’a été exécutée pour ce diff documentaire. Le suivi #119 couvre également la clarification suppression/archivage et la demande répétée sur un projet déjà archivé ; cette MR en couvre une partie, sans solder son ledger.
Co-authored-by: Automata <automata@shikanime.studio>
StephaneTrebel
left a comment
There was a problem hiding this comment.
La garantie générale d’idempotence signalée dans ma précédente revue a bien été retirée ; ce constat est corrigé. Les deux nouvelles suggestions, non bloquantes, visent à rendre la reprise après échec et le résultat de l’archivage compréhensibles ; liens locaux vérifiés et CI « Test app build » verte, sans build local ni recette de suppression, et le périmètre plus large de #119 reste ouvert.
Co-authored-by: Automata <automata@shikanime.studio>
StephaneTrebel
left a comment
There was a problem hiding this comment.
Les deux suggestions de lisibilité sont prises en compte : les étapes après échec sont explicites et liées aux journaux, et l’archivage est distingué d’une sauvegarde restaurable. Aucun nouveau constat ; trois liens locaux et la structure Markdown vérifiés, CI « Test app build » verte, sans build local ni recette de suppression exécutés (le suivi plus large #119 reste ouvert, aucun ledger modifié).
Quoi
Nouvelle section « Archivage d'un projet » dans Administration > Projets : ordre des opérations (verrouillage, nettoyage des ressources externes, archivage), comportement en cas d'échec (statut échoué, erreur 422, suppression rejouable), conflit de modification (409), et déverrouillage par un administrateur.
Pourquoi
La console a fiabilisé la suppression concurrente des projets (verrouillage du projet pendant la suppression externe, rejet de l'archivage d'un snapshot obsolète, nettoyage externe piloté avant l'archivage). Le comportement observable par les utilisateurs et administrateurs méritait d'être documenté.
Références